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ABSTRACT 


Marine forces are expeditionary in nature yet require 
the full range of Public Key Infrastructure (PKI) services 
at deployed sites with limited bandwidth and access to their 
respective Registration Authority (RA). The development of 
a PKI solution for the tactical arena is a fluid and complex 
challenge that needs to be answered in order to ensure the 
best support of tactically deployed forces. Deployed Marine 
forces will need the capability to issue and re-issue 
certificates, perform certificate revocation, and perform 
key recovery within the command element of the deployed 
unit. Since the current United States Marine Corps (USMC) 
PKI was not designed with the tactical environment in mind, 
the full extent of PKI deficiencies for field operation is 
unknown. This thesis begins by describing public key 
cryptography, the implementation and objectives of a USMC 
PKI, and the components necessary to operate a PKI- Next, 
tactical issues that have been identified as areas of 
concern along with their proposed solutions are presented. 
Supporting material describes design issues, such as 
scalability and interoperability, and technical challenges, 
such as certificate revocation lists (CRL), key escrow and 


management of tokens - 
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I. INTRODUCTION 

Throughout history, military leaders have regarded 
information superiority as a key enabler of victory. The 
Marine Corps must be able to take advantage of superior 
information converted to superior knowledge to achieve 
"decision superiority" - better decisions arrived at and 
implemented faster than an opponent can react, or in a 
noncombat situation, at a tempo that allows the Marine Corps 
to shape the situation or react to changes and accomplish 
its mission. The Marine Corps of the future will use 
superior information and knowledge to achieve decision 
superiority, to support advanced command and control 
capabilities, and to reach the full potential of dominant 
maneuver, precision engagement, full dimensional protection, 
and focused logistics. 

Marine forces are expeditionary in nature and require 
the full range of Public Key Infrastructure (PKI) services 
at deployed sites with limited bandwidth and access to their 
respective Registration Authority (RA). Deployed Marine 
forces will need the capability to issue and re-issue 
certificates, perform certificate revocation, and perform 
key recovery within the command element of the deployed 
unit. In addition, tactical requirements dictate that 
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provisions must be made to accommodate issuing certificates 
to allied and coalition forces during combined/coalition 
operations. 

The current plan for the implementation of the United 
States Marine Corps (USMC) PKI calls for centralized 
certificate management and decentralized registration. 
Within this type of architecture, the USMC will issue 
certificates to all military and Marine civilian personnel 
by October 2002. However, the tactical environments that 
the USMC faces present a unique set of challenges to this 
architectural approach. Since the current United States 
Marine Corps (USMC) PKI was not designed with the tactical 
environment in mind, the full extent of PKI deficiencies for 
field operation is unknown. 

To further understand the tactical challenge, one must 
appreciate the basic definition of tactical. For purposes 
of this document, tactical is defined as "any environment 
where networked computers exchange protected information in 
support of combat operations". 

The nature of the tactical arena invariably suggests 
that the USMC must employ alternative solutions, at least in 
part, to institute PKI tactically. It is recognized that 
injecting PKI into tactical operations will significantly 
change the way units prepare for deployments. The challenge 
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aj^isss from th© nssci to ©Itsx th© airchitsctuirs to fit th© 
r©c 3 uir©iti©nts of th© tactical ar©na. Which ©l©ni.©nts of 
traditional PKI will b© need©d within th© tactical ar©na? 
How will that b© accomplish©d? For exampl©, moving a 
fortification Authority (CA) away from th© contralized 
rogion of th© curront architoctur© and clos©r to th© Local 
Registration Authorities (LRAs) will affect th© maintenance 
of secure and stable connectivity with remaining CAs. 
Hence, the USMC needs to address specific tactical PKI 
requirements. Based on experience and technical knowledge, 
the USMC has identified areas of concern, which is the focus 
of the thesis. 

A. THESIS OUTLINE 

This thesis begins with a description of the tactical 
PKI problem. Chapter II introduces public key cryptography 
which is an emerging technology that supports the 
cryptographic services of confidentiality, authenticity, 
integrity and non-repudiation. Public key cryptography 
differs from conventional cryptography in that two 
mathematically related, yet different keys are used for 
encryption and decryption, instead of identical copies of 
the same key. Where conventional cryptographic services is 
limited to supporting confidentiality and integrity, public 
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key cryptography can be used to support confidentiality and 
integrity, as well as authentication and non-repudiation. 

The last section of Chapter II, describes the various 
aspects of a PKI. 

Chapter III describes the USMC PKI implementation. The 
main six USMC PKI entities are presented in a top down 
sequence starting with the Root Authority, followed by the 
Certificate Authority (CA), Registration Authority (RA) , 
Local Registration Authority (LRA), Trusted Agents (TA), and 
ending with the End-Users. Objectives for the USMC PKI are 
explained and a current timeline for the implementation and 
deployment of the USMC PKI is given. 

In Chapter IV tactical issues and proposed solutions 
are identified and described. Tactical issues concerning 
key escrow/recovery, PKI directory services, and certificate 
revocation lists are presented. Additional topics include 
the management of tokens, transportation, biometrics, and a 
discussion of the loss or capture of personnel and 
equipment. 

Chapter V summarizes the key points of the thesis and 
presents general conclusions based on the thesis research. 
The implementation of a tactical PKI within the USMC is a 
complicated and diverse challenge that requires careful and 
methodical planning to ensure that tactical forces are 
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deployed with a workable solution for tactical requirements. 
Chapter V identifies and briefly discusses additional issues 
for further research. 
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II. PUBLIC KEI CRYPTOGRAPHY AND INFRASTRUCTURES 


A. INTRODUCTION 

This Chapter introduces public key cryptography as an 
emerging technology that provides mechanisms supporting 
confidentiality, authenticity, integrity and non¬ 
repudiation, which will be described later. Public key 
cryptography differs from conventional cryptography in that 
two mathematically related, yet different keys are used for 
encryption and decryption, instead of identical copies of 
the same key. Where conventional cryptography is limited to 
providing confidentiality and integrity, public key pairs 
can be used to provide confidentiality and integrity, as 
well as authentication and non-repudiation. The last 
section of this Chapter will explain what encompasses a PKI 
in detail to further understand the technical challenges. 

B. CRYPT06R2VPHY 

Cryptography means hidden writing, the practice of 
using encryption to conceal text [Ref 22, p. 23] . 
Cryptography does for electronic information what locks do 
for printed information. The information is protected by 
scrambling it in such a manner that it can be unscrambled 
only with a secret key [Ref 21, p. 286]. 
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Cryptography has become increasingly important in the 
last few years. The increased use of networking and the 
availability of commercial cryptographic products has fueled 
this increased interest. Years ago cryptography was mainly 
a national security concern for protecting the 
confidentiality of classified information. 

Recent developments have seen a greater concern for 
security in the commercial as well as the DoD environment 
and the additional need for authenticity and integrity have 
become increasingly important. 

Some of the increased interest in the use of 
cryptography is due to the services that are provided by 
Public Key Cryptography. Public key cryptography can 
provide a superior means of authenticating oneself across a 
network than traditional password protections. Public key 
cryptography supports digital signatures which are important 
for communications so that the recipient of a message can be 
assured that the message really came from the person who 
claims to be the sender. Digital signatures also provide 
assurance that the content has not changed since it left the 
sender. Integrity and authentication of messages have 
become important within the Defense Message System (DMS) and 
various other USMC applications. Standards, such as Secure 
Multipurpose Internet Mail Extension {S/MIME) may stimulate 
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greater use of secure mail over the Internet, if vendors 
implement the standard such that interoperability among 
vendor's secure mail products is achieved. 

Encryption and digital signatures are also important 
for electronic transactions. Encryption can be used to 
protect SBU data from unauthorized observation and digital 
signatures can be used to ensure that the claimed individual 
really is authorizing an order. For the USMC, digital 
signatures will prove useful in tactical areas by providing 
assurance of the integrity of a request for resupply, 
authenticity of the request for resupply, and verification 
that the request was received. 

Conventional cryptography, which has historically been 
used, provides for confidentiality and integrity. In order 
to successfully use public key cryptography, certain 
services such as key generation, key distribution, key 
revocation, etc. are required. A public key infrastructure 
of sufficient size and scope to adequately address all USMC 
needs must be deployed to make use of the technology. 

C. PUBLIC KEY CRYPTOGRAHY 

Conventional cryptography (also called symmetric-key) 
and public-key cryptography (also called asymmetric-key) are 
both based on complex mathematical algorithms and use keys. 
Symmetric-key cryptography schemes provide message 
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confidentiality by requiring the sender and receiver to 
share a common, secret key. Each user must trust the other 
not to divulge the common key to a third party. These 
systems encrypt large amounts of data efficiently; however, 
they pose significant key management problems in networks of 
more than a very small number of users, and today are 
typically used in conjunction with public-key cryptography. 
Examples of this include, electronic commerce by protecting 
credit card transactions and a variety of ticketing systems 
from manipulation and fraud. 


Cryptography (1) 



symmetric key or secret key 


Figure 1. Symmetric Key Cryptography 

In 1976, two cryptographers at Stanford University, 
Whitfield Diffie and Professor Martin Heilman, invented a 
method whereby two parties could agree on a secret message 
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key without the need for a third party/ an off line 
exchange, or transmission of any secret values [Ref 21, p. 
298] . The Diffie-Hellman method is based on the concept of 
a private-public key pair. 

Public-key cryptography schemes require each party to 
have a key pair: a private key, which must not be disclosed 
to another user, and a public key, which may be made 
available in a public directory. The two keys are related 
by a hard one-way function, so it is computationally 
infeasible to determine the private key from the public key. 
Since the security of the private key is critical to the 
security of the cryptosystem, the private key is often 
stored in software with password protection; alternatively, 
the private key can be stored in a secure hardware token 
that prevents direct access or tampering. 

There are key management problems associated with both 
symmetric—key cryptography and public—key cryptography. 
Symmetric-key cryptography schemes provide message 
confidentiality by requiring the sender and receiver to 
share a common, secret key. Each user must trust the other 
not to divulge the common key to a third party. They pose 
significant key management problems in networks of more than 
a very small number of users. If confidentiality is 
compromised it becomes increasingly difficult to determine 
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the point of compromise with a greater number of users. 
Public-key cryptography schemes require each party to have a 
key pair: a private key, which must not be disclosed to 
another user, and a public key, which may be made available 
in a public directory. Problems here arise with the 
availability of the public directory and maintenance of the 
public directory. One must ask: Is the public directory 
current and does it have the public key that is required? 

Public-key systems simplify the key management problems 
associated with symmetric-key encryption; however, even more 
importantly, public-key cryptography offers the ability to 
efficiently implement digital signatures. 



Figure 2. Public Key Cryptography 
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D. CONFIDENTIALITY, AUTHENTICATION INTEGRITY AND NON¬ 
REPUDIATION 

Public key cryptography schemes provide mechanisms 
supporting confidentiality, authenticity, integrity and non¬ 
repudiation for the network and will now be described. 

1. Confidentiality 

Confidentiality is sometimes called secrecy or privacy. 
It involves keeping a message or data private. Typically it 
is provided by encryption. 

2. Integrity 

It is a measure of the state of wholeness or goodness 
of the resource or the degree to which it is accurate, 
complete, genuine, and reliable [Ref 21, p.25]. Typically 
it is provided by digital signatures in such a way that a 
message or data is not alterable without detection 

3. Authentication 

Authentication refers to mechanisms for confirming the 
identity of people, systems or information. Mechanisms 
include passwords, access tokens, biometrics, watermarks, 
and in networked environments digital signatures. They 
ensure that the quality or condition of information is 
authentic, trustworthy, and genuine and that users or 
senders of information are who they claim to be. 
Authenticity is typically provided by digital signatures. 
The DoD PKI digital signature has been evaluated by the 
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General Accounting Office as meeting the requirements to be 
legally binding electronic substitute for a "wet signature" 
on documents [Ref 28, p.l]- 
4. Non-reptidxation 

Non-repudiation means that a person cannot deny having 
sent or processed information. It is typically implemented 
by requiring the sender to digitally sign the information. 
At a later time a judge or a third party can establish that 
the sender really did send a message. 

E. PUBLIC KEY INFRASTOUCTUBE 

A PKI encompasses "Certificate Management" and 
"Registration" functions and "Public Key enabled 
applications". 



Figure 3. What's a Public Key Infrastructure? 







1. Certificate Management 

Certificates, similar to identification cards, are 
electronic credentials that are used to certify the online 
identities of individuals, organizations, and computers. 
Certificates are issued and certified by CAs. A certificate 
signed by a trusted third party binds an individual's public 
key to the individual. Thus we trust that any use of the 
public key in essence speaks for its owner. 

Certificate Management provides for the generation, 
production, distribution, control, accounting and 
destruction for public key and public key certificates. 
Certificate Management is composed of a Certificate 
Authority (CA) and Directory Services. The CA plays the 
role of a trusted third party that certifies the identity of 
the possessor of a private key used for digital signature or 
key exchange by providing digitally signed certificates for 
users and components. Certificate management will also 
provide key recovery for private keys associated with 
encryption certificates to support data recovery. 

Information contained in the certificate includes a 
version number, the issuer's name, a serial number, the 
individual or entity's name, public key, validity period for 
use and optionally other attributes or privileges [Ref 24, 
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Section 8, p.21]. The certificate management process in the 

DoD PKI will be responsible for: 

Digitally signing each certificate, thereby certifying the 
identity of the end entity possessing the corresponding 
private key. 

Managing the revocation of certificates. Two methods will 
be used to manage the revocation of certificates: (1) 
Publishing and posting a Certificate Revocation List (CRL) 
to the directory, and (2) Providing a mechanism for a real¬ 
time check of the revocation. 

Archiving all certificates and CRL's even after expiration 
or revocation, to support non-repudiation of digital 
signatures. 

Provide tools and procedures for personnel responsible for 
user registration status [Ref 1, p. 2,3]. 


To ensure consistent, proper usage of different 
assurance levels across the DoD, PKI certificates will be 
issued with assurance levels in accordance with the minimum 
criteria listed below: 

Class 2: (Formerly Basic) This level is intended for 
applications handling information of low value 
(Unclassified) or protection of system high information in a 
low to medium risk environment such as SIPRNET. This 
assurance level does not require that the end user register 
in person and their cryptography can be software based. 

Note: DoD will use Class 3 certificates to support Class 2 
applications. 

Class 3: (Formerly Medium) This level is intended for 
applications handling medium value information in a low 
medium risk environment. This assurance level is 

appropriate for applications that typically require 
identification of an entity as a legal person, rather than 
merely as a member of an organization. This assurance level 
requires that the end user register in person and their 
cryptography can be software based. 

Class 4: (Formerly High) This level is intended for 
applications handling medium to high value information in 
any environment. These applications typically require 
identification of an entity as a legal person, rather than 
merely a member of an organization. This level requires a 
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hardware token for protection of the private key material. 

This assurance level requires that the end user register in 
person, and that the cryptography be hardware based. 

Class 5: This level is intended for applications 
handling classified information in a high-risk environment 
{over an open unprotected network). This assurance level 
requires National Security Agency (NSA)-approved Type I 
cryptography [Ref 1, Appendix c-1]. 

To achieve interoperability of certificates across all 
DoD components, the DoD Class 3 identity and encryption 
certificates will have a minimum/common set of attributes 
(i.e. citizenship, government/non-government employee, 
service, or agency affiliation) [Ref 1, p. 2]. 
Interoperability between DoD and its vendors and contractors 
will be accomplished, in the near term, by using External 
Certification Authorities (ECAs). 

Primarily CA Directory Services are used to distribute 
certificates and CRLs to users and applications. In 
addition, directories can be used to distribute other end- 
entity information such as e-mail address, phone numbers, 
postal address, etc. A directory system must be viewed from 
at least two perspectives: user access and administration. 
User access includes the suite of access protocols, as well 
as the means of controlling access to information within 
that repository. Also the directory system should be 
configured to use digital signatures for strong 
identification and authentication (I&A) as well as non¬ 
repudiation, of administrator actions. 
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2. Regis'tra'tion 

Although the CA is ultimately responsible for 
identification and authentication during the certificate 
creation process, the CA may assign some of the 
responsibility to the Registration Authority (RA) and Local 
Registration Authority (LRA). In general the RAs/LRAs are 
responsible for authenticating the identity of users and 
entities during the creation of certificates. Certificates 
may also contain additional information and it is the 
responsibility of the RA/LRA to verify the accuracy of this 
information. The requirements for the RA/LRAs and 
associated tools are defined in the US DoD X.509 Certificate 
Policy [Ref 1, p.3]. 

Registration will be done through a workstation and 
web-based application. Hardware tokens will be used to help 
establish assurance of the process. A registration 
workstation with standardized procedures for the request and 
delivery of certificates will be based on commercial 
standards and technologies. A desired goal is a common set 
of processes and tools that supports certificate 
registration at all levels of assurance. The only 
difference in the registration process being user 
identification procedures and tokens used to protect the 
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keys. This will allow all users to register with the 
appropriate CA server through an LRA. 

3. Applications euid Standards 

A PKI supports the employment of cryptographic security 
services by providing public key information, certificates 
and Certificate Revocation Lists (CRLs) to cryptographic 
applications, which encrypt and decrypt data and sign and 
verify signatures. To use public key technology, 

application developers must understand the supporting 
infrastructure's policies, usage and interfaces. There are 
a number of commercial off the shelf applications available 
today that use PKI certificates. Because of the newness of 
the standards and products, however, there can be some 
functional and interoperability problems between vendors' 
products. The Defense Information Systems Agency (DISA) and 
National Security Agency (NSA) are actively working with the 
vendors and the standards communities to achieve standard 
specifications and product implementations to ensure 
interoperability. The DoD is committed to ensuring that 
these DoD specifications are consistent with emerging 
commercial and National Institute of Science and Technology 
(NIST) Federal standards to support DoD interoperability 
requirements [Ref 1, p. 3]. The DoD PKI will also continue 
to track new and evolving Internet Engineering Task Force 
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(IETF) standards to ensure that the most widely accepted 
commercial standards are fully leveraged to support maximum 
interoperability in the future. 

4. Biometrics 

Security is enhanced by using multi-factored 
authentication. Commonly used factors are: something you 
know, something you have, something you are, and something 
you do. Password-based systems typically use only the first 
factor, i.e. something you know. A token adds an additional 
factor, and represents something you have. Two factor 
authentication has proven to be much more effective than 
single factor because the something you know factor is so 
easily compromised or shared. Biometric identification adds 
another factor providing something you are. Biometrics is 
the technology of measuring and statistically analyzing 
human body characteristics. Biometric identification can be 
classified into two groups: static biometric and dynamic 
identification. 

Static biometric identification captures and verifies 
physiological characteristics of an individual. Common 
static biometric characteristics include fingerprints, eye 
retina, and facial features. 


20 



Dynamic biometric identification uses behavioral 
characteristics of an individual. Common dynamic biometric 
characteristics include voice and handwriting. 

Biometric authentication requires readers or scanning 
devices, software that converts scanned information into 
digital form, and, wherever the data is to be analyzed, a 
directory that stores the biometric data for comparison with 
entered data. When converting a biometric input, the 
software identifies specific points of data as match points. 
The points are processed using an algorithm into a value 
that can be compared with the stored biometric value when a 
user tries to gain to access. 

A smartcard token can be enhanced to include the 
something you are factor. Prototype designs are available, 
which use thumbprint biometrics from the thumbprint reader 
on the surface of the token in addition to the PIN in order 
to unlock the services of the token. Alternatively, a 
thumbprint biometric value, a retinal biometric value, or 
other biometric information can be stored on the card, which 
is checked against data obtained from a separate biometric 
input device. Similarly, Something you do such as typing 
patterns, handwritten signature characteristics, or voice 
inflection biometric values can be stored on the token and 
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be matched against data accepted from external input 
devices. 

If the system is designed to allow for graded 
authentication, the administrator can assign different 
security labels based on the number and type of login 
factors deemed necessary to enable access to the requested 
data or services. For example variations include. Token 
only. Password only, Biometric only. Password and Token, 
Biometric and Token, Biometric and Password, and Biometric 
with password and Token. 

F. CONCLUSION 

This chapter introduced public key cryptography and 
gave a brief overview of what is required of a public key 
infrastructure. It covered utilization of public key 
cryptography to achieve confidentiality, authentication, 
integrity, and non-repudiation. Different assurance levels 
across DoD PKI certificates were introduced for future 
reference. A brief overview of how PKI will be implemented 
within the USMC will be provided in Chapter III. 
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III. USMC PKI IMPLEMENTATION 


A. INTRODUCTION 

Soon, nearly every Marine and DoD employee will need 
PKI services to support tactical users and daily activities. 
These services are becoming increasingly important in 
networked environments where communications and transactions 
occur over unsecured channels. The need for 
confidentiality, integrity and digital signatures can be 
provided by cryptography, which in turn needs the support of 
a PKI. In this chapter specific details of the PKI 
pertinent to the USMC will be discussed. 

B. USMC PKI HIERARCHICAL STRUCTURE 

The USMC PKI builds on the DoD PKI and consists of six 
entities in a top down hierarchical structure beginning with 
the Root Authority housed at the National Security Agency 
(NSA), Finksburg, MD. 

1. Root Authority 

The National Security Agency (NSA) will initialize and 
operate the Root Authority. The Root Authority will 
register and certify all DoD Certificate Authorities (CA). 
If the root CA is compromised then the integrity and 
security offered by the systems it supports is lost. The 
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root authority is not involved in daily functions of the ?KI 
system. 



Figure 4. DoD PKI Infrastructure 

2. Certificate Authority (CA) 

The Defense Information Systems Agency (DISA) has been 
designated as the DoD, (e.g., USMC), Certificate Authority 
(CA) . DISA Will have at least four CA sites. Currently, 
there are two CAs. One CA is located at Defense Mega Center 
(DMC) Chambersburg, PA and the other resides at DMC Denver, 
CO. Two yet to be determined overseas sites, one in Europe 
and another in the Pacific are planned. These CAs are 
connected to the NIPRNET. A second set of CAs will be 
connected to the SIPRNET. 
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As the DoD CA, DISA will be the sole authenticator for 
the USMC Registration Authorities (RAs) and provide 
directory and certificate services and system management. 
The CA itself may generate some certificate information; but 
in general the CA is responsible for collecting information 
from authorized sources and correctly entering that 
information into a to-be-signed certificate. The CA is 
bound by its Certificate Practice Statement (CPS) to include 
only valid and appropriate information, and to maintain that 
due process is exercised in confirming the information. 

3. Registration Authority <RA) 

The USMC Registration Authority (RA) is the Marine 
Corps Information Technology Network Operation Center 
(MITNOC) Chief Information Officer (CIO). The MITNOC CIO 
will oversee the implementation of the USMC PKI. The USMC 
RA will register all USMC Local Registration Authorities 
(LRAs), servers, and maintain/submit certificate revocation 
lists (CRLs) to the CA. The RA will make the initial 
distribution of End-User certificates during the 
implementation of PKI. The RA will use the RA workstation 
to interact with the CA and will use a token reader and 
token for system access. The RA will manage LRA groups and 
LRA certificates. The RA also issues server certificates. 
The purpose of a server certificate is to act as an identity 
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certificate for server authentication when establishing a 
Secure Socket Layer (SSL) session. 

4. Local Registration Authority (LRA) 

Local Registration Authority's are local entities that 
identify and authenticate End-Users and register them as 
part of the certificate issuance process. LRAs will be 
designated in accordance with the USMC Network 
regionalization concept, where eight regions are currently 
being identified. Unit Commanders within each region will 
designate Information Systems Security Officers (ISSOs) 
within their region to act as the LRA. Custom software has 
been developed to provide a graphical user interface (GUI) 
for the LRA. This workstation and a web browser are used to 
register users during the certificate issuance process. The 
LRA workstation provides tools for creating lists of users, 
assigning unique identifiers (UID) and creating One-Time 
Passwords (OTP), which are needed by users to complete the 
certificate issuing process. The LRA workstation provides 
secure mechanisms for delivering the user lists to the CA 
server. These mechanisms include: file upload that uses a 
mode of the Secure Socket Layer (SSL) protocol that 
authenticates both the client and server system. LRAs also 
have the capability to reset users' login OTP, should the 
user fail to login properly after three attempts with the 
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OTP when trying to complete the certificate issuance 
process. LRAs are required to use token readers and tokens 
to access the system. 

5. Trusted Agents (TA) 

Trusted Agents (TAs) are local entities that verify 
end-users personal data, and perform face-to-face 
authentication. Trusted Agents assist RAs and LRAs when it 
is not geographically feasible for End-Users to physically 
come to an RA or LRA location. Unit Commanders within each 
region will designate Information System Security Officers 
(ISSOs) within their region to act as Trusted Agents on an 
as needed basis during and after the implementation of PKI. 

6. End-Users 

End-Users will use the USMC PKI in their daily duties, 
digitally signing and encrypting messages in support of 
various USMC functions. The End-User is responsible for 
interacting with the LRA for obtaining and maintaining 
personal certificates. 

C. USMC PKI OBJECTIVES 

Marine Corps networks support a variety of the Marine 
Corps' departmental and enterprise-wide applications. 
Several emerging joint applications are being developed and 
fielded with integrated public key mechanisms and PKI 
interfaces. Examples include Electronic Document Access 
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(EDA ), Defense Travel Systems (DTS), Medium Grade Services 
(MGS), Navy Marine Corps Intranet (NMCI), and Joint Computer 
Aided Acquisition Logistical Support (JCALS). 

DoD PKI policies are established at three fundamental 
levels: the entire DoD, the DoN (including the Marine 

Corps), and locally at the command level. DoD policies are 
the highest level of policies affecting the entire PKI and 
are the broadest of all policies. DoD policies are not 
designed to cover every detail of implementing a PKI. DoN 
and local policies cannot conflict with the overall DoD 
guidance, only enhance the overarching DoD policy. One of 
the more influential policy documents affecting DoD policy 
on PKI is Public Key Infrastructure Roadmap for the 
Department of Defense Version 2.0, Revision C, 08 September 
2000. It states numerous dates for the implementation and 
deployment of the DoD PKI. 

DoD must (deploy an infrastructure capable of issuing 
Class 3 DoD PKI certificates to each member of the 
organization by October 2000 [December 2001]. 

All DoD users will, at a minimum, be issued a Class 3 
PKI certificate by October 2001 [October 2002]. 

To accelerate improved protection of information 
exchanged within the DoD, all e-mail sent within the DoD 
will be digitally signed by October 2001 [October 2002]. 

DoD Components will begin to issue Class 4 certificates (on 
hardware tokens) in replacement of Class 3 certificates 
(software based) by January 2002 [October 2002]. 

Systems using PKI technology to protect SBU 
information over unencrypted networks, such as e-mail, must 
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laigrate to the use of Class 4 certificates and hardware 
tokens by 31 December 2002 [December 2003]• 

The dates in brackets are the new DoD PKI Milestones 
approved 12 August 2000. With the timetable already 
established the Marine Corps must aggressively pursue its 
PKI implementation plan, strictly adhering to the 

established DoD PKI standards, to meet the objectives set 
forth in the above policies. 

D. CONCLUSION 

This chapter described the Marine Corps' role within 
the DoD's policies and overall strategy for PKI 

implementation. The USMC PKI Hierarchical Structure was 
explained. Marine Corps specific responsibilities and 
objectives for the implementation of a PKI within the USMC 
were presented and discussed. How tactical issues affect 
Marine PKI implementation will be discussed in Chapter IV. 
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IV. TACTICAL ISSUES AND PROPOSED SOLUTIONS 


A number of focus groups were held between August 1999 
and January 2000 to gather user requirements for both the 
Target Key Management Infrastructure (KMI) and DoD PKI. As 
a result of those focus groups, two requirements documents 
were produced. 

• Future KMI Operational Requirements Document 
(Initial Draft), 29 October 1999 

• DoD Public Key Infrastructure User Requirements, 
29 February 2000 

The goal of the focus group that met 7-8 June 2000 was 
to gather feedback on the contents of these two documents, 
and capture additional requirements that are not currently 
included in either of these documents. An area of 
particular interest for feedback on the PKI User 
Requirements document was Tactical PKI Requirements. From 
the results of that focus group, (Reference 18), some issues 
of concern included: Personnel, Physical Security, Hardware 
and Software, Transportation, Biometrics, Key 
Escrow/Recovery, Directories, Certificate Revocation List, 
Management of Tokens, Loss or Capture of Personnel and 
Equipment. For the remainder of the Chapter, I will define 
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the issues more deeply and give what I believe to be 
workable solutions to these issues. 

A. TACTICAL PKI REQUIREMENTS 

To understand the tactical PKI challenge, one must 
appreciate the basic definition of a tactical PKI. For 
purposes of this document, a tactical PKI is defined as "a 
PKI in support of combat operations". 

In the tactical environment, a tactical community 
should be able to replicate portions of the directory that 
are needed for a specific tactical operation without having 
to depend on the availability or reachback to the primary 
directories [Ref 18, #177]. In Chapter III the definition 
of a Certification Authority (CA) and Local Registration 
Authority (LRA) were given. A major difference between the 
two is that the CA is responsible for all aspects of the 
certificate issuance and management process. The LRA is a 
local registration agent that verifies end users and 
registers them prior to certificate issuance. If an LRA is 
deployed with enough pregenerated certificates and is held 
responsible for all aspects of the certificate issuance and 
management process it should be upgraded to a local tactical 
CA. This would allow for all the functions of the CA to 
take place locally and not rely on reachback to the primary 
directories. 
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While the USMC PKI can support most tactical 
requirements through the use of a local tactical CA, there 
are still some issues concerning the completeness of the 
services provided by the local tactical servers. Since the 
tactical environment does not always provide easy access to 
the infrastructure elements (i.e., CA Servers, directory), 
services requiring such access may suffer. The services 
that suffer may include rapid mobilization, rapid compromise 
recovery required by tactical operations, key recovery, and 
support for remote users. 

A tactical PKI includes the personnel and processes to 
perform PKI functions that include all processes including 
the availability of LRA personnel, the availability of 
tokens, etc. The tactical PKI should not inhibit the rapid 
mobilization of tactical communications and information 
systems. It should not degrade communications and should 
minimize bandwidth consumption as part of its basic design. 
It should support the rapid addition and removal of public 
key certificates to enable rapidly changing user roles and 
privileges. In addition, the deployment of a tactical PKI 
necessitates the need for a token that must meet tactical 
environment constraints. 

The local tactical CA and associated directories will 
be required to support combined/joint coalition operations. 
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Certificate management services will need to be self- 
contained/supported on isolated C2 networks. 
Interoperability with Allied/Coalition and NATO systems is 
crucial [Ref 18, #146]. 

B. ISSUES C0NCEBNIM6 PERSOMMEL, PHYSICAL SECURITY, 

HARDWARE AND SOFTWARE, TRANSPORTATION AND BIOMETRICS 

1. Personnel 

Some tactical PKI personnel related concerns are: Will 
a tactical PKI result in a "Zero-add" of personnel to units? 
If it is not a "Zero-add", then what are the additional 
personnel requirements? Do we need to redesignate personnel 
(i.e.. Staff Sergeant to Warrant Officer) to maintain a 
"Zero-add" approach? 

With the Total Force Structure locked in place the 
procurement of additional personnel is highly unlikely. The 
Marine Corps should look at initiating a program designed to 
train and retain personnel in the Information Technology 
field. Many Marines are trained to perform specific 
Information Technology jobs, but when it is time to reenlist 
they opt to exit the Marine Corps for greater pay and a 
higher quality of life. 

As with other critical Military Occupation Speciliaties 
(MOS's) the Marine Corps needs to add an incentive for that 
Marine to continue with a career in the Marine Corps. One 
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possible solution is to require a payback period in return 
for training in certain IT skills. Reenlistment bonuses, 
and annual bonuses should be reviewed as other possible 
incentive tools. An examination of current occupational 
field distributions should be reviewed for redundancy and 
duplication, upon elimination of redundancies an opportunity 
for personnel to take training and transfer to new duties 
should be provided. If the data is classified, the 
personnel operating the equipment will also require an 
appropriate level of security clearance. The system must be 
capable of being managed by personnel with a basic/minimum 
knowledge of Information Technology and PKI system training 

Allowing a Sergeant or Staff Sergeant the opportunity 
for selection to Warrant Officer can help to maintain a 
"Zero-add" approach to personnel requirements. Also, adding 
an Information Technology Management Military Occupation 
Specialty (MOS) to the Limited Duty Officer (LDO) board 
much, like the Ordnance and Logistics Field has done, can 
help in retaining Marines for a full career. 

2. Physical Security 

Physical security protection is an important aspect of 
a PKI. PKI components need to be secured to preclude loss 
from theft of components and to safeguard the data. 
Handling classified equipment is not new to the Marine 
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Corps. The physical security of classified PKI components 
can be maintained along side already existing classified 
items. Two-person integrity (TPI) can be implemented when 
securing and shipping equipment needed for the operation of 
a tactical PKI. The computer equipment designated as the 
primary workstation for the LRA will be kept within a secure 
area. The information contained on the LEIA machine is 
considered sensitive but unclassified (SBU). The personnel, 
as mentioned above will be screened for the proper clearance 
required for the task assigned. Again, this is not new to 
the Marine Corps. 

3. Hardware and Software 

The hardware (HW) and Software (SW) for the LRAs and 
users should be well thought out and specifically designed 
for tactically deployed units. If it is deemed necessary to 
have tactical LRAs or a local tactical CA, serious 
consideration should be given to the workstation 
requirements. The readers and tokens should withstand a 
host of environmental scenarios such as sand, heat, and 
humidity and should also be small and lightweight. 

A medium assurance (Class 3) PKI LRA requires the 
following software: Windows NT 4.0, and NETSCAPE 4.05 or 
greater, (US version only), with NETSCAPE Communicator, and 
the Local Registration Authority (LRA) SW and Graphical User 
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Interface (GUI) available from Director, Communications 
Security Material (DCMS). 

A medium assurance (Class 3) PKI LRA requires the 
following hardware: Pentium PC, Token Reader, standalone 
printer. Tokens and when required Internet connectivity. 
End-Users require a PC with Windows NT 4.0, NETSCAPE 4.05 or 
greater with NETSCAPE Communicator and Internet 
connectivity. End-Users will require token readers after 
the migration to the medium and high assurance (Class 4) PKI 
that uses hardware based cryptographic tokens. 

4. Transporta'tlon 

The total tactical PKI system must be transit cased and 
have a 2-man lift maximum weight, 200 lbs [Ref 18, #161] . 

Transport requirements should address airlift and vehicle 
capabilities (i.e., roll-on or sling loaded). 

Locking weatherproof cases need to be provided to 
transport all associated equipment as specified in 
subparagraph 3. Standard 9 cubic foot boxes can be utilized 
or the owning unit can manufacture boxes. A standard case 
made out of plastic with shock resistant material lining 
inside would be preferable. 

5. Biometrics 

More biometrics needs to be implemented into the 
tactical PKI [Ref 18, #226]. The implementation of 
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biometrics into a tactical PKI needs to be incorporated 
during this early stage of the development process. 

There are many environmental concerns that need to be 
considered when implementing biometrics into the tactical 
environment. Sand, water, extremes in temperature are just 
a few. An implementation of biometrics for the tactical 
environment can be fingerprint match points stored on a 
token and in devices such as cell phones. The token does 
not need a fingerprint to operate. The cell phone with a 
fingerprint reader embedded at the base needs a match 
between what it reads with what is stored in its directory 
and what match points the token provides. In this case the 
cell phone can only be activated if there is a three way 
match between the points stored on the token with what is 
provided by the fingerprint reader and what is stored in the 
cell phone. 

C. KEY ESCROW/HECOVERY AND DIRECTORIES 

1. Key Escrow/Recovery 

Key recovery systems work in a variety of ways. Early 
"key recovery" proposals relied on the storage of private 
keys by a trusted third party. Recently, techniques that 
use "escrow agents" or "key recovery agents" have been 
proposed. These systems build an encrypted copy of the 
"session key" that is stored with the data. The key used to 
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encrypt the session key is only known to the recovery agent. 
Some systems split the ability to recover keys among several 
agents. 

Key escrow/recovery supports a number of important 
services, such as a backup mechanism that ensures that a 
tactical component will continue to have access to its own 
encrypted archive in the event that a public or private key 
is lost. The system put in place should address the 
capability of rapid access to all current and previous 
encrypted data. It is not difficult to design and implement 
small-scale systems that successfully recover keys or 
plaintext according to some access policy. The difficulties 
arise from ensuring that a large-scale system, or system of 
systems, does not inadvertently or maliciously leak data. 
All key recovery systems require the existence of a highly 
sensitive and highly available secret key or collection of 
keys that must be maintained in a secure manner over an 
extended time period. These systems must make decrypted 
information quickly accessible to the correct tactical 
component. These basic requirements make the problem of 
general key recovery difficult, expensive and potentially 
too insecure and too costly for many applications and many 
users. 
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The impact of key recovery can be considered in at 
least three dimensions: Risk, Complexity, and Economic Cost. 
Risk for a key recovery system deals with the failure of key 
recovery mechanisms that can jeopardize the proper 
operation, underlying confidentiality, and ultimate security 
of the encryption systems. Threats include improper 
disclosures of keys, theft of valuable key information, or 
failure to be able to meet tactical demands. A fully 
functional key recovery infrastructure is an extraordinarily 
complex system with numerous new entities, keys, tactical 
requirements, and interactions. The true economic cost of a 
key recovery infrastructure is difficult to model. 

It is still possible to make sound judgments about the 
basic system elements, shared by all key recovery systems. 
Key recovery systems are inherently less secure, more 
costly, and more difficult to use than similar systems 
without a recovery feature [Ref 12, p 18]. Key recovery 
degrades many of the protections available from encryption, 
such as absolute control by the user over the means to 
decrypt data. 

In spite of these difficulties key escrow and key 
recover services must be provided locally in tactical 
situations. A tactical component cannot rely on reachback 
to recover encryption private keys. 
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2. Directory Services 

Directory services must be available/tailored to 
support the user community of the tactical network. 
Deployed tactical components require real-time support, and 
the occasional "down" CA or directory will degrade an 
operation's effectiveness. Local tactical directories need 
to be self-contained, so that they do not need to rely on 
reachback for updates or replication. Two techniques can be 
employed to minimize directory size to conserve bandwidth 
during replication and updates. The first is to issue 
certificates on a one-to-many basis instead of on a 1-to-l 
basis. Within a tactical component you may have three 
identical sub components with identical traits and 
characteristics that carry out the same tasks. If the only 
one of the sub components is used at a time, then you only 
need to issue certificates to the sub component conducting a 
tactical operation. The second is to replicate only the 
part of the directory that is needed for a tactical 
operation. However, the local tactical CA should still have 
the same real-time capability for certificate revocation, 
key recovery and certificate status checking. 

D. CERTIFICATE REVOCATION LIST (CRL) 

Certification Practices Statements describe operational 
aspects of a PKI. They need to be tailored to specific 
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environments. Depending on the nature of an operation or 
tactical scenario, differing procedures will need to be 
established regarding operations such as compromise 
notification/recovery, certificate revocation, certificate 
revocation delay (i.e., minimum acceptable time to post 
revocation to CRL or update Online Certificate Status 
Protocol services), and frequency of directory updates. 

1. CSl, Distribution Scheme 

Certificate revocation is just as important in tactical 
situations as it is in non-tactical situations. Thus CRLs 
need to be maintained to support tactical network users. 
Currently, the DoD PKI uses X.509 version 3 (X.509v3) CRLs 
that have extension fields that can provide many advantages. 
X.509v3 certificates allow CAs to define the extension 
fields as they see fit. Extension fields may contain 
additional information that can be specified for optional 
use within a PKI. One possible use for extension fields is 
to contain a CRL number. If each CRL issued for a given 
‘^s^tificate population is assigned a sequentially increasing 
number, users can determine if they are missing a CRL. The 
extension fields can also be used to reduce the bandwidth 
required for updates of CRL information. One such technique 
uses the concept of Delta-CRLs. 
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Rather than issue a full CRL, the local tactical CA can 
simply issue a list of the changes that have occurred since 
the last time a full CRL was issued. Users who maintain 
their own CRL database can use a delta-CRL to keep their 
copies updated without having to download and process all 
the entries of a full CRL, saving bandwidth and computing 
time. An extension field in the CRL designates a CRL as 
either a full CRL or delta-CRL. 

The extension fields also allow a "revocation reason" 
to be specified for each revoked certificate in a CRL. This 
field allows CRLs to be partitioned by revocation reason. 

Routine revocations, for example, those due to name 
change or lost password, can be placed on a separate CRL 
from one listing certificates that have been revoked for 
security reasons. The list of routinely revoked 
certificates can be distributed less frequently without 
affecting the possibility of using a compromised 
certificate. 

CRLs can also be partitioned on a component basis. 
Thus if a user needs to verify the validity of a certificate 
of a user from a specific component, they only need to check 
the CRL from that specific component rather than the full 
CRL. 
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All of these CRL extensions still do not overcome the 
fundamental problem of a lag in time between when a 
certificate is compromised and when its revocation appears 
on an end users CRL. Even with partitioned CRLs and 
frequent delta-CRL issuance, there is still a window of 
opportunity when a compromised certificate could be used. 

2. Emergency Revocation 

The tactical PKI should have a provision for emergency 
revocation in case of overrun or capture which can be 
executed in a worst-case time of 15 minutes, with 5 minutes 
being the desired time [Ref 18, #149]. 

The decision to execute emergency revocation is 
predicated on the current tactical situation. If the 
tactical component commander believes that due to the 
current tactical situation that it would be in the best 
interest of the overall operation to revoke the certificates 
of the component, then there should be an efficient means to 
do so. Situations may include but are not limited to, 
overrun by the enemy or the detection of a traitor in the 


component. 

The tactical 

component 

stranded without 

PKI 

credentials 

would have 

to rely 

on other types 

of 


cryptography when communicating until the current situation 
can be corrected. 
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It can be implemented efficiently if the certificates 
for each tactical component in a tactical operation are 
identified by their tactical component name. If this is 
done, all certificates for a tactical component can be 
revoked by just sending back a high priority message with 
just the name of the tactical component. By using just the 
name, bandwidth would be conserved. 

E. MANAGEMENT OF TOKENS 

1. Managemen-b of Tokens 

Service members will perform jobs that will require the 
use of their PKI tokens. If they show up to perform their 
jobs and their token fails, how quickly can the 
infrastructure react to resolve the problem? 

Tactical tokens should be issued and managed in the 
same manner that weapons are issued and managed. The local 
tactical CA should deploy with enough pregenerated 
certificates and corresponding tokens for all members of the 
tactical component and some spares to prevent the need for 
reach back to CONUS. Marines who use PKI-enabled 
applications to conduct daily garrison business will use 
their garrison token. Marines in support of a tactical 
operation who are in need of a tactical token and 
certificate will be issued a sanitized tactical token on an 
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as needed basis allowing the Marine to leave behind their 
garrison token. 

The argument for a sanitized tactical token, which is 
different from the garrison token is based upon the fact 
that currently garrison tokens are intended to include DoD 
personnel information {medical/dental records, dependent 
information, etc.) in addition to PKI cryptographic data and 
processing [Ref 29, p.6]. It would be extremely unwise (and 
a departure from current practice) to carry this personal 
information into a tactical situation. 

When a tactical operation is begins, the local tactical 
CA sends a message to the RA notifying it of certificates 
issued and the corresponding user identification associated 
with those certificates. When the operation ends the tokens 
will be turned in for storage and a message will be sent to 
the RA notifying it as to which tokens have been returned. 
Although the technology allows for more than one private key 
on a token, I believe that the use of distinct sanitized 
tactical token should be issued if there is a risk that the 
garrison token may become comprised. Private encryption 
keys associated with deployable tactical accounts must be 
locally escrowed and the escrowed keys must be deployed to 
support in-theatre key recovery. The certificates/tokens 
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associated with the tactical accounts will need to be 
revoked upon exercise/operation termination. 

2. Types of Tokens 

Before the Marine Corps commits to a Common Access Card 
(CAC) or other token for the tactical environment it needs 
to ensure that the tokens and readers can hold up under the 
various tactical conditions. 

In non-tactical contexts, the token used to store a 
users private key is currently the CAC. A CAC is very 
similar to your VISA credit card. The magnetic stripe on 
the back allows digitized data to be stored on the card in a 
machine-readable format. The stripe's storage capacity is 
about 1000 bits and anyone with the appropriate read/write 
device can view or alter the data. For increased protection 
and to make the client token more powerful, an integrated 
circuit was incorporated into the card and the integrated 
circuit card has now become known as the Smart Card. Smart 
cards are now available with over 20 Kbytes of memory. 
Smart cards have both pros and cons. There are concerns 
with smart cards as to how well they will stand up to a host 
of environmental scenarios, such as sand and sea salt spray, 
common to Marine Corps tactical situations. Proper 
maintenance is required for both the smart card and the 
smart card reader. Recent exercises have proven that sand 
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is an environmental hazard to smart card readers that can 
render them useless. 

One alternative is a key-sized token that the 
individual can carry on a key ring and plugs into the USB 
port of the machine being used. CYLINK'S Minikey is an 
example of this type of token. It is no bigger than a 
vehicle key. The USB port can be covered with a rubber 
grommet when not in use. How well this will work with 
handheld devices, such as a Personal Digital Assistant (PDA) 
and cell phones, still needs to be addressed. One advantage 
of smart cards is their ability to store additional 
information, such as a bar code and a picture for increased 
authentication in addition to keys in support of the DoD PKI 

F. LOSS OR CAPTURE OF PERSONNEL AND EQUIPMENT 

1. Rapid Voiding of Memory 

Tactical threats that must be accounted for include: 
overrun and capture, equipment destruction, loss of nodes of 
the network due to jamming, loss of personnel due to 
causalities, etc. Thus all tactical equipment, cell phones. 
Personal Digital Assistant, and PKI tokens must support 
rapid voiding of memory in case of capture or must be 
constructed with self-destructing tamper proof technology. 

This includes, a method for zeroizing the local 
tactical CA data (e.g. CA directory) that can be executed by 
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a switch or a command sequence initiated by the 
administrator with the proper token. 

2. Suspension of Credentials 

There should be a capability for suspending 
certificates for individuals whose status has become 
unknown, and for reinstating the individual's certificates 
once active status has been confirmed. 

The following scenario illustrates the need for this 
capability. Suppose an individual disappears behind enemy 
lines and later attempts to communicate with the tactical 
network. If the user's certificate has been revoked, this 
communication will be denied. 

One way to support the capability of 
suspending/reinstating user's certificates is through the 
use of "revocation reason codes" in CRLs. Thus, a CRL can 
list the certificates that are currently suspended until 
proper notification that the certificate has been 
compromised. If a suspended certificate is used, the 
message will still be accepted but it will be flagged as 
questionable. 

6. CONCLUSION 

This chapter has described some of the tactical issues that 
affect the Marine Corps' role, policies and overall strategy 
for a PKI implementation. Proposed solutions to the 
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tactical effects were discussed. A summary, conclusion and 
recommendations for further research will be discussed in 
Chapter V. 
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V. DISCUSSION AND CONCLUSIONS 


A. DISCUSSION 


The United 

States 

Marine Corps 

(USMC) Public 

Key 

Infrastructure 

(PKI) is 

defined as 

the framework 

and 


services that provide for the generation, production, 
distribution, control, and tracking of public key 
certificates. It is a major element of the Marine Corps 
Information Assurance (lA) strategy that is based on a 
"Defense-in-Depth" concept. 

At present, the DoD PKI program Management Office 
(PMO), in conjunction with the Defense Information Systems 
Agency (DISA), Federal agencies, and Services are working 
against an existing timeline to provide a standard PKI 
capability. Since the technology is still evolving, the 
Marine Corps hopes to influence current products with Marine 
Corps requirements by using a strategy of early 
participation with current vendors- This, in turn, should 
minimize the use of Government-Off-the-Shelf (GOTS) 
development and leverage existing commercial PKI technology, 
standards, and services. 

Both the USMC Class 3 PKI and the target Class 4 PKI 
employ centralized certificate management and decentralized 
registration. Using this architecture, the USMC will issue 
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certificates to all it members, to include USMC (DoD) 
civilian personnel, by October 2002. However, the tactical 
environments that the military faces present a unique set of 
challenges to this architectural approach. Since the 
current DoD PKI was not designed with the tactical 
environment in mind, the full extent of deficient operation 
in the field is unknown. The nature of the tactical arena 
invariably suggests that the USMC must employ alternative 
solutions, at least in part, to institute a PKI tactically. 
The challenge, in part arises from the need to alter the 
architecture to fit the requirements of the tactical arena. 
Based on experience and technical knowledge, the USMC has 
identified areas of concern, which was the focus of this 
document. 

The Marine Corps is ideally suited for joint, allied, 
and coalition warfare. It is the only Service specifically 
tasked by Congress to operate as an integrated combined arms 
force providing a joint force enabler in three dimensions- 
sir, land, and sea. The Marine Corps operates as part of a 
larger joint force. Marine Corps Strategy 21 [Ref. 21] 
guides a Marine Corps capable of accomplishing its specified 
and implied tasks derived from the guidance in the National 
Security Strategy, the National Military Strategy, and other 
strategic dociiments. Marine Corps Strategy 21 also supports 
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Joint Vision 2020, which builds upon and extends the 
conceptual template established by Joint Vision 2010 to 
guide the continuing evolution of the Armed Forces. Marines 
must analyze and influence this evolution. 

As first described in Joint Vision 2010, the potential 
of the information revolution will be used to transform 
today's capabilities for maneuver, strike, logistics, and 
protection to become dominant maneuver, precision 
engagement, focused logistics, and full dimensional 
protection. To build the most effective force for 2020, we 
must be fully joint: intellectually, operationally, 

organizationally, doctrinally, and technically [Ref 26, p. 
2 ] . 

Three aspects of the world of 2020 have significant 
implications for the US Armed Forces: 

First, the United States will continue to have global 
interests and be engaged with a variety of regional actors. 

Second, potential adversaries will have access to the 
global commercial industrial base and much of the same 
technology as the US military. 

Third, we should expect potential adversaries to adapt 
as our capabilities evolve [Ref 26, p. 5,6]. 

A difference between Joint Vision 2010 and Joint Vision 
2020 is the addition of the term full spectrum dominance. 
The term full spectrum dominance implies that US forces are 
able to conduct prompt, sustained, and synchronized 
operations with combinations of forces tailored to specific 
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situations and with access to and freedom to operate in all 
domains—space, sea, land, air, and information [Ref 26, p. 
8] . Upon realizing the potential of the information 
revolution, the transformation of the joint force to reach 
full spectrum dominance rests upon information superiority 
as a key enabler and our capacity for innovation. 

Joint Pub 1-02 contains the following two definitions: 

Information onvironment-the aggregate of individuals, 
organizations, and systems that collect, process, or 
disseminate information, including the information itself. 

Information superiority-the capability to collect, 
process, and disseminate an uninterrupted flow of 
information while exploiting or denying an adversary's 
ability to do the same. 

Information, information processing, and 
communications networks are at the core of every military 
activity. 

B. CONCLUSIONS 

Addressing the requirements for the deployment of a PKI 
in the USMC tactical environment is a difficult and ongoing 
task. As mentioned earlier, the USMC is ideally suited for 
joint, allied, and coalition warfare. It is the only 
Service specifically tasked by Congress to operate as an 
integrated combined arms force providing a joint force 
enabler in three dimensions: air, land, and sea. The Marine 
Corps operates as part of a larger joint force. Operation 
in a Joint environment imposes additional requirements 
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regarding the of commonality of equipment and applications 
to support a tactical PKI. 

A PKI Pilot for Tactical USMC needs to be conducted. 
The purpose of the Pilot should be to deploy Public Key 
Technology to understand operational benefits and 
shortfalls. The pilot program will allow leveraging of 
cryptographically supported commercial security technology 
where applicable. It will also facilitate the development, 
integration and testing of Government off the Shelf (GOTS) 
cryptographically supported security technology to meet 
specific USMC tactical requirements. To produce useful 
results, any worthwhile pilot would have to be conducted in 
a coalition network/environment. A pilot program will also 
allow the USMC to validate current solutions envisioned for 
the tactical arena. The USMC needs to continue work on a 
tactical PKI Operational Requirements Document (ORD) , 
separately from the DoD PKI ORD, so that USMC specific 
requirements can be met. 

The USMC needs to establish and coordinate tactical PKI 
forums and workshops. Also the USMC should not plan in a 


vacuum. 

Looking 

outside to 

other services 

and 

to 

the 

private 

sector can 

assist in 

the search for 

a 

workable 

solution 

. It is 

important to 

realize that 

each 

of 

the 


Services' specific missions and roles will create different 


55 




definitions of "tactical". Of course, the nontactical PKI 
and the tactical PKI, will have to interoperate. 

C. RECOMMENDATIONS FOR FUTURE RESEARCH 

Below are some recommendations for future research: 

1) Some tactical networks are on the SIPRNET, and some 
are not. There should be some research into the 
requirements for tactical/deployed unit's networks (i.e., 
SIPRNET). 

2) Identify and discuss the full impact on privacy and 
security of using a DoD Common Access Card. For example, 
given that the future military ID card will be a smart card 
containing PKI certificates, what are the possible 
implications and risks? What information should/should not 
be contained on the smart card? 

3) Which weapons systems/applications are candidates 
for PK enabling (i.e., require PKI services of 
authentication, integrity, non-repudiation, confidentiality, 
or availability)? For example, would existing 
artillery/call for fire systems benefit from the additional 
authentication/data integrity mechanisms provided via PKI 
digital certificates? What are the disadvantages? Would 
implementing a PKI increase the length of time that it takes 
to request support from a call for fire system? Would 
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implementing a PKI degrade the Quality of Service of a call 
for fire system or enhance it? 

4) Systems using PKI technology to protect SBU 
information over unencrypted networks, such as e-mail, must 
migrate to the use of Class 4 certificates and hardware 
tokens by 31 December 2002. Given this deadline, what 
standard token should be used? Smart Cards are currently 
being discussed, but with the increasing varieties of Smart 
Cards what standards (i.e., power currently 5 volts, mobile 
phone components currently 3 volt) are to be adhered to? 

D. SIIMMARY 

This thesis has identified and described a few of the 
issues challenging the deployment of a PKI in the USMC 
tactical environment. Some of the issues will be overcome 
with the use of a well thought-out and robust tactical 
token. Also, the use of CRL extensions will help maintain 
current and efficient certificate directories. Equipment 
self-protection will also aid in assuring security. The 
development of a solution for the tactical arena is a fluid 
and complex challenge that needs to be addressed in order to 
ensure the best support of tactically deployed forces. 
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APPENDIX. ABBREVIATIONS AND ACRONIMS 


ASD 

C2 

C3I 

CA 

CAC 

CIO 

CPS 

CRL 

DISA 

DII 

DMC 

DMS 

DoD 

Don 

DTS 

EDA 

60TS 

GDI 

lA 

I&A 


Assistant Secretary of Defense 
Coitimand and Control 

Command, Control, Communications and 

Intelligence 

Certificate Authority 

Common Access Card 

Chief Information Officer 

Certificate Practice Statements 

Certificate Revocation List 

Defense Information System Agency 

Defense Information Infrastructure 

Defense Mega Center 

Defense Message System 

Department of Defense 

Department of the Navy 

Defense Travel System 

Electronic Document Access 

Governments off the Shelf 

Graphic User Interface 

Information Assurance 

Identification and Authentication 
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ISSO 

JCALS 

KMI 

LDO 

LRA 

MOS 

MGS 

MITNOC 

NIPRNET 

MMCI 

NSA 

ORD 

OTP 

PDA 

PKZ 

PM 

PMO 

RA 

S/MIME 

SBU 


Information System Security Officer 

Joint Computer Aided Acquisition Logistical 

Support 

Key Management Infrastructure 
Limited Duty Officer 
Local Registration Authority 
Military Occupation Specialty 
Medium Grade Service 

Marine Corps Information Technology Network 
Operation Center 

Nonclassified Internet Protocol Routing 
Network 

Navy Marine Corps Intranet 
National Security Agency 
Operational Requirements Document 
One Time Password 
Personal Digital Assistant 
Public Key Infrastructure 
Program Manager 
Program Management Office 
Registration Authority 

Secure Multipurpose Internet Mail Extension 
Sensitive But Unclassified 
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SIPBMET 


Secret Internet Protocol Routing Network 


SSL 

TA 

UID 

US 

USMC 


Secure Socket Layer 
Trusted Agent 
Unique Identifiers 
United States 

United States Marine Corps 
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